Andy Ihnatko on iOS 4’s Location-Tracking Log

Best piece I’ve seen on the “consolidated.db” location-tracking log:

A few reality checks, lest I inadvertently do a Glenn Beck number on all of you, here:

  • This database isn’t storing GPS data. It’s just making a rough location fix based on nearby cell towers. The database can’t reveal where you were…only that you were in a certain vicinity. Sometimes it’s miles and miles off. This implies that the logfile’s purpose is to track the performance of the phone and the network, and not the movements of the user.

  • A third party couldn’t get access to this file without physical access to your computer or your iPhone. Not unless you’ve jailbroken your iPhone and didn’t bother resetting its remote-access password… or there’s an unpatched exploit that would give Random Person On The Internet root access to your phone.

  • It’s pretty much a non-issue if you’ve clicked the “Encrypt iPhone Backup” option in iTunes. Even with physical access to your desktop, a no-goodnik wouldn’t be able to access the logfile.

But still! What a nervous can of worms. This is an open, unlocked file in a known location in a standard database format that anybody can read. If someone has physical access to your Mac — or remote access to your user account — it’s a simple matter of copying a file and opening it. And while the logfile can’t tell someone that you were at a specific house, it can obviously tell your boss that you went to the Cape on the day you called in sick.

It’s worse than that, though, because even if you are encrypting your backups, it’s also available to anyone who has physical access to your iPhone.

The big question, of course, is why Apple is storing this information. I don’t have a definitive answer, but the best at least somewhat-informed theory I’ve heard is that consolidated.db acts as a cache for location data, and that historical data should be getting culled but isn’t, either due to a bug or, more likely, an oversight. I.e. someone wrote the code to cache location data but never wrote code to cull non-recent entries from the cache, so that a database that’s meant to serve as a cache of your recent location data is instead a persistent log of your location history. I’d wager this gets fixed in the next iOS update.

★ Thursday, 21 April 2011